home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19980901-19981211
/
000038_news@newsmaster….columbia.edu _Thu Sep 17 13:44:08 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
7KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA04514
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 17 Sep 1998 13:44:07 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA26959
for kermit.misc@watsun; Thu, 17 Sep 1998 13:44:07 -0400 (EDT)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.unix.questions,comp.unix.solaris,comp.unix.unixware.misc,comp.protocols.kermit.misc,comp.dcom.modems
Subject: Re: looking for paging notification software
Date: 17 Sep 1998 17:44:04 GMT
Organization: Columbia University
Lines: 122
Distribution: inet
Message-ID: <6trhp4$l26$1@apakabar.cc.columbia.edu>
References: <6tojgu$1mp$1@nnrp1.dejanews.com> <6tot43$6ju$1@apakabar.cc.columbia.edu> <6tpahb$vbq$1@nnrp1.dejanews.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.unix.questions:130890 comp.unix.solaris:174263 comp.unix.unixware.misc:30898 comp.protocols.kermit.misc:9212 comp.dcom.modems:239957
In article <6tpahb$vbq$1@nnrp1.dejanews.com>, <apatnaik@aircom.com> wrote:
: A couple more questions:
:
: 1. Is the TAP protocol, as you say below, something that
: is installed on the sending computer, i.e my computer which
: contains my application that sends pages? I can't assume
: anything about the paging service provider or the receiving side.
:
C-Kermit 6.0 comes with a script that implements the TAP protocol:
http://www.columbia.edu/kermit/ck60.html
http://www.columbia.edu/kermit/pagers.html
Whether you can send an alpha page depends on the paging service.
: 2. My pages need to work in numeric-only pagers, but if
: a client has an alpha pager, would the mechanism I
: use to send pages to numeric-only pagers work?
:
No. There is a fundamental difference between numeric and alpha pages.
Numeric pages are sent by dialing a number and then, after it answers,
entering the message by pushing additional numbers on the telephone keypad,
i.e. sending DTMF signals (Touch Tones). If you are using a modem, all
the modem does is dial -- none of its modulation/demodulation/protocol
features are engaged at all.
Alpha pages are sent over a modem-to-modem connection. A modem must
answer on the far end, and carrier is required. The message is sent as
characters rather than DTMF tones.
There are, in fact, three ways to send an alpha page. First, you can make
a voice call to the paging service and speak to human who transcribes the
message and pager ID, and then sends the page. Second, you can dial the
paging service with a modem and a terminal or emulator, and type in the
pager ID and message in an interactive dialog. Third, you can dial the
paging service with a computer and modem and use Telocator Alphanumeric
Protocol to send the page. The third is best because it includes error
detection and correction (checksums, retranmission, etc) and confirmation
that the page was sent.
The second method might seem easier, and can be scripted, but lacks not
only error detection/correction and confirmation, but also a uniform
interface -- every paging service uses a different dialog.
: 3. Is there any example code that uses C-Kermit for
: sending numeric pages. How reliable is it?
:
C-Kermit simply sends a dialing command to the modem, and therefore must
depend on the capabilities of the modem, since Kermit itself (or any other
software running on your computer) does not have access to the sounds
(waveforms) on the telephone line. Only the modem "hears" them and can
interpret them (as you would if you were using a real telephone), and
pass along the interpretation to the computer in the form of result codes.
It's all done in the dial string that is sent to the modem. Example:
ATDT7654321@123456#;
This works if your modem treats "@" as a command to "wait for quiet answer"
(i.e. phone answers but there is no carrier). However, some modems don't
implement this very well, or at all, or consistently with other modems.
In that case, you need hardwired pauses:
ATDT7654321,,,,123456#;
One comma = 2 seconds (unless change the modem's default configuration); use
as many as necessary according to what your paging service does when it
answers the phone (speaks a long message, plays Muzak for 5 minutes, etc).
In some cases, a combination might work best:
ATDT7654321@,,,,123456#;
(wait for answer, and then wait for recorded message to stop playing).
The message, in this example "123456" is normally terminated by "#", and
the final ";" tells the modem to return to command mode immediately rather
than wait for carrier, since there never will be carrier.
Thus the Kermit commands are quite simple:
set modem type usr ; or whatever you have
set line /dev/cua0 ; or whatever device you are using
set speed 2400 ; doesn't really matter much
dial 7654321@123456#; ; send the page
At this point the modem will respond with OK, or maybe NO DIALTONE, BUSY,
or (if we are lucky) NO ANSWER (depending on how well the "@" works), and
then Kermit will report success or failure depending on what the modem
said.
How reliable is it? This is not really a question about the software,
it's a question about the modem. In my experience, most modems do not
handle this task well at all. Also, it's a question of whether the paging
service lets you "type ahead" -- what happens if tones are sent while a
recorded message is playing? Etc etc. All of this is beyond software
control; all the software can do is ask the modem to dial -- the rest is
up to the modem. And the paging service.
To achieve the best possible reliability requires rather intensive study
of your modem manual, detailed observation of the behavior of the paging
service under a variety of conditions, and much experimentation. Even then,
there can be no guarantees that the paging service will get the message,
or that the paging service will relay the message to the pager, or that
the person carrying the pager will notice the message. TAP solves the first
problem. The second problem is solved by paging services that hold the
message until the pager confirms receipt (these are called 2-way paging
services). But the only solution for the last problem is to require a
some form of reply from the pagee, such as a voice callback.
I suspect that some modems will perform better than others. In fact, modems
could be built that were well suited to numeric paging, but they would need
some different functions than modems we have now. And paging services would
need to be changed to work with these modems. For example, modems would
need a real "wait for answer" (as opposed to the "@" directive, whose
definition is usually something like "wait for 5 seconds of silence), and
then the paging service would need to emit a special tone when it was ready
to receive the page, similar to the "bong" sent when making credit-card
calls. Then you could use the modem's "wait for bong" feature (if it has
one) before sending the page, to ensure it is not sent before the service
is ready for it.
- Frank